Computer networks have become the dominant medium for the communication and exchange of data. The advent of the Internet in particular has spurred further developments in the field of computer networking. Today, larger computer networks can comprise robust, sophisticated systems capable of exchanging enormous amounts of data at impressive rates among a vast number of distributed computer systems.
These larger computer networks may be implemented to include a variety of network components. Common network components (both hardware and software) are integrated to enhance the performance of the network, and to provide additional network functionality. These components may include dedicated servers that offer additional storage and processing capabilities; network routers that provide optimized packet routing and shared network access; and firewall software to provide network security. Often, each component must be individually configured to provide the desired level of security, privacy and efficacy. Accordingly, a principle challenge in the field of computer networking is to design these multi-component, distributed systems to be able to efficiently and consistently exchange large amounts of data while effectively preventing unauthorized infiltration and limiting network failures.
The field of network design has developed in response to address this need. The goal of this particular field is to optimize the architecture of the network by selecting the appropriate component hardware devices and configuring the devices to be capable of communication with other network constituents and to meet desired performance levels.
However, configuring a network can be a tedious and error prone process. Hardware may behave unexpectedly and differently than intended or designed. Furthermore, each device in a network is typically locally configured, but as part of a network, any misconfiguration may have a global impact which can be difficult to identify and impossible to correct remotely. Errors in configuration can result in packet (data) loss, additional latency, vulnerability to security breaches or even total network communication failure.
In order to avoid disruption to a production network, one conventionally employed technique is for network engineers to construct a test network of the network component devices (usually according to a smaller scale) that will comprise a potential network. The potential network is subsequently tested according to one or more configurations to verify the network's viability prior to implementing the configuration to a production network.
Currently, the components used in a test network are typically interconnected by physical wires. For practical reasons, this requires that all of the equipment used in the testing be located in the same general physical location, and typically requires a large inventory of network component devices to enable comprehensive testing. Accordingly, storage for the network component devices may require a considerable amount of space; likewise, a deployment of the test network may also require additional physical lab space. Additionally, it may be difficult to remotely perform network design and testing from the inventory according to this technique.
For example, misconfigured devices may be inaccessible remotely. Likewise, sharing equipment among distributed locations may be inconvenient and prohibitively impractical. The cost of provisioning fully-functioning testing labs at discrete locations can be enormous. Finally, since previously assembled configurations are not typically stored, test networks often require individual assembly, and physically setting up and reconfiguring a test environment for each and every test network can be inefficient and labor-intensive.
A different technique conventionally employed is referred to as router tunneling. Router tunneling is typically implemented by encapsulating network protocol within a different delivery protocol. Router tunneling is commonly used to create virtual private networks (VPNs). By creating a VPN between two or more devices (typically discrete computers), the devices may be locally configured and the transfer of data may be monitored. However, the behavior of the network devices along the transfer route (e.g., routers) may not always be consistent with the behavior of the devices in a traditional network (e.g., not a VPN). For example, under typical router tunneling configurations, the routers comprising the network need to be specifically configured to allow for router tunneling, and thus may not be configured to transmit data without router tunneling.
Since local networks may not require router tunneling, the behavior of the router tested using router tunneling may be inconsistent with how the router will actual behave in practice. Moreover, the configuration of the tunnels may be overwritten when duplicating subsequent test configurations. Furthermore, other network devices may not support tunnels. For example, firewalls and network servers typically do not support router tunneling. Accordingly, a test network may be exceedingly difficult to simulate via router tunneling with any appreciable accuracy.
Yet another conventional technique is to simulate a test network by virtually emulating the network devices (e.g., routers) comprising the test network. Software emulating the features and the behavior of the routers is deployed and tested for network feasibility prior to the physical implementation of the network according to the network design. However, emulation of network devices cannot capture all aspects of a real network. For example, configuration and simulated behavior is strictly limited to the simulation models according to the software, which may not be entirely comprehensive. Often, this manifests as a limited number of available commands and a lack of comprehensive support.
Additionally, for emulation of a network device to be possible, simulation models must be available to correspond to the version or iteration of the particular network device of the design. These simulation models may not be available for some time after the release of a particular device, if at all. For example, a common practice for network device manufacturers is to release firmware updates for released products to address defects discovered after release. A product can be “flashed” (e.g., have its operating software updated) with the updated firmware to remove the addressed defects. However, even if emulation software for the particular device is available, the software may also need to be updated to correspond with firmware updates in order to align with the behavior of the actual device. This inconsistency may result in wasted time due to unnecessary or incorrect configuration.